Not applicable.
The present invention relates to information processors and more particularly to a search system for generating links to a first information set which is referenced in a second information set and to a system which automatically inserts tags into records which can be used by other applications to identify specific types of information within the record.
The computer networking industry is constantly searching for new and improved ways to facilitate communication between network users and to access and manipulate data stored on network databases. To this end one common way to access data stored on a network has been to employ universal resource locators (URLs) common to the Internet. A URL is essentially an address which includes a plurality of fields which together operate as a pointer to information stored at a specific database address on a network. The address fields typically include two general information types including server specifier and specific data information. The server specifier information specifies a server which is linked to a database which includes specific information required. The specific data information provides a key which can be used by a server to determine the precise data required by a URL. For example, a first and typically broadest field for data stored on a hospital database may identify the hospital server (e.g., St. Mary""s, Springfield, historical server). A narrower field may include specific data information indicating a specific hospital patient (e.g., a nine digit patient ID number).
When a URL is transmitted, the network routes the URL to the URL specified server. When the server receives the URL, the server parses the URL to identify the specific data information, retrieves the information and then performs some function (e.g., manipulation, providing the information back to the requesting network user, etc.) on the retrieved information.
One problem with URLs is that servers rely heavily on URL fields to identify URL specified data. As networks become more complex and as users and applications require access to relatively more specific data, additional fields are added to URLs and the URL scheme becomes much more complicated. For example, initially a hospital may include only a single server and therefore, once the hospital is specified in a single URL field, the server is known. However, as the hospital system expands and additional servers are added to the hospital system, additional server specifying fields need to be added. As another example, in a primitive system it may be sufficient to access complete ECG records for physician review. However, as a system becomes more complicated it may become desirable to enable access to more specific ECG record data such as heart rate.
Accessing specific data is further complicated when an application requires many small data segments from one or more records. For example, in a physician""s report it may be advantageous to link references within the report to specific data stored at addresses linked to the report via the network. For instance, the desired links may be to an image, a heart rate and a diagnosis for a particular patient. In this case, three separate URLs would have to be specified by a user and linked to referencing text in the report, one URL for each of the image, heart rate and diagnosis. While such linking is advantageous, in many cases such linking is never contemplated because of the complexity of the required URL addressing scheme.
Recently another method and tool for accessing/manipulating data within a specific record has been developed which specifies universal xe2x80x9ctagsxe2x80x9d which can be used within a record to earmark specific data types. An exemplary xe2x80x9ctaggingxe2x80x9d language is the extensible markup language (XML). The tags are to be used by processor applications which are familiar with the tags to identify specific information types. Applications which are capable of recognizing tags are referred to hereinafter as xe2x80x9ctag enabledxe2x80x9d and records which include such tags are likewise referred to as tag enabled. Tags are typically paired including a xe2x80x9cbeginxe2x80x9d tag and an xe2x80x9cendxe2x80x9d tag identifying the beginning and the end of a specific data type within a corresponding record. For example, in a patient record, a xe2x80x9c less than patient id greater than xe2x80x9d tag may specify the beginning of a field including a patient ID and a corresponding xe2x80x9c less than /patient id greater than xe2x80x9d tag may specify the end of the patient ID field. Similarly, a xe2x80x9cbegin imagexe2x80x9d tag may specify the beginning of an image field while an xe2x80x9cend imagexe2x80x9d tag specifies the end of the image field. Using a URL scheme a record can be retrieved by a tag enabled application. Thereafter, the application parses the record to identify specific data types required by the application and uses the identified data types.
Thus, tags and tag enabled applications can be combined with URLs to overcome some of the complexity associated with URL data specification within a specific record. Nevertheless, linking record segments and references together via URLs and tags requires knowledge about URL and operation and formats. For example, to link a reference in a first record to a segment in a second record, first the second record address has to be specified and the segment tags have to be specified. Then, the URL address of the second record and the tags of the record segment to be linked have to be linked to the reference in the first record. Because many record producers (e.g., physicians) do not have required URL and tag knowledge, despite the advantages associated with such linking, most such linking is foregone.
U.S. patent application Ser. No. 09/326,177 (hereinafter xe2x80x9cthe ""177 referencexe2x80x9d) entitled xe2x80x9cMethod for Specifying Enterprise-Wide Database Address Formatxe2x80x9d which was filed by the present inventor on Jun. 4, 1999 describes a system whereby URLs are automatically generated for data within a record thereby streamlining the process of linking references in one record to data stored at other network locations. To this end information in a first record is searched for data references (DRs) which reference other records. When a DR is identified, other record information is sought for constructing a URL address to the record associated with the data reference. After a URL corresponding to the record associated with the data reference is constructed, a link to the referenced record is formed. Exemplary links include hyperlinks, importation of the referenced record information into the referencing first record or electronic document, etc. Both real time and batch processing are contemplated.
A wrinkle of complexity is added to the referencing scheme whereby modifier references (MRs) may be used to further specify a specific record or record segment when a DR is identified. In this case, when a DR is identified, the record is further examined to identify modifier references (MRs) which identify a specific segment of a record which is associated with the data reference. When an MR is located, additional information is sought within the record for building an address to the record or record segment referenced by the DR/MR combination. Once again, a link is created between the referencing record and the referenced record or record segment.
Unfortunately, the ""177 reference system also has several shortcomings in the area of html linking. The ""177 reference recognizes that various search rules can be employed by a processor assigned the task of constructing referenced record addresses. Nevertheless, in the interest of simplifying explanation of the novel concepts in the ""177 reference, the ""177 reference assumes a simple searching rule wherein only the term immediately preceding a DR is examined to locate an MR. For example, where an ECG DR is located, only the term preceding the ECG term is sought for MRs (e.g., admission, post-op, etc.).
While such a simple MR search rule is advantageous for explanation purposes, it has been recognized that such a simple rule is most likely inadequate for most practical automatic linking systems for a number of reasons. First, such a simple rule would likely fail to identify many intended links. For instance, while many physicians may enter the phrase xe2x80x9cpost-op ECGxe2x80x9d into a report, other physicians may enter the phrase xe2x80x9cpost-op exemplary ECGxe2x80x9d to refer to a similar record. In this case, the intermediate term xe2x80x9cexemplaryxe2x80x9d would render the phrase xe2x80x9cpost-op exemplary ECGxe2x80x9d unrecognizable as a DR/MR combination. In fact, in this regard, an MR and a corresponding DR may be separated by several (e.g., 10) terms or an MR may follow a DR.
Second, even where a rule is adopted which accommodates terms between an MR and a DR, there may be instances where two DRs fit the required relationship with respect to a single MR or where two MRs fit the required relationship with respect to a single DR. For example, the phrase xe2x80x9cpost-op ECG and admission reportxe2x80x9d may be included in a record. In this case, a rule which specifies that an MR may be within five terms of a DR would be confusing as the exemplary phrase could reference a post-op ECG or an admission ECG or both.
Third, it has been recognized that in the case of certain advantageous linking features, simple address constructing rules may cause additional confusion. For example, it would be advantageous to have a system which supports more than a single MR level. For instance, where xe2x80x9cECGxe2x80x9d is an exemplary DR, a first level MR (i.e., MR1) may be xe2x80x9cpost-opxe2x80x9d, indicating a post-operation ECG and a second level MR (e.g., MR2) may be xe2x80x9cheartbeat waveformxe2x80x9d. While entering a report, a physician may reference a xe2x80x9cpost-op ECG heartbeat waveformxe2x80x9d corresponding to a specific segment of a post-op ECG report which includes a heartbeat waveform. In this case, the system may support links to an entire ECG report (for example, the most recent ECG report), an entire post-op ECG report (independent of whether or not the post-op ECG report is the most recent report), a graph corresponding to the post-op ECG heartbeat waveform, a graph corresponding to a most recent ECG heartbeat waveform, or to any combination of an ECG report, a post-op ECG report, the post-op ECG heartbeat waveform or the most recent ECG heartbeat waveform. Unfortunately, there is no way for a processor to determine which of several links should be formed using a simple rule such as checking the term prior to a DR to identify an MR.
Generally there are two different types of automatic hyperlink generating systems including systems that generate hyperlinks effectively in real time (i.e., as text is being entered) and systems that generate hyperlinks in batch form. Real time systems are advantageous in that links are updated routinely as text is entered into a document or as document text is altered and hence links are always current. Thus, a link can be used almost immediately after text (e.g., a DR) associated with the link is entered by a system user. One problem with real time systems, however, is that system users are often distracted when text changes appearance during a linking action to earmark the text as a hyperlinked phrase. For instance, some systems may change black text to blue text to identify a link when a link is to be made.
Batch type hyperlink generating systems, as the label implies, receive a text segment or, in some cases, may receive an entire document, and search the entire text segment or document to identify suitable DRs and/or DR/MR combinations to be hyperlinked to other documents. Thus, for instance, after a batch system user uses a word processor to create a document, the document is submitted to the batch hyperlinking system which may identify fifty separate hyperlinkable phrases within the document text and thereafter generates fifty hyperlinks within the document to fifty other documents. Batch type linking systems have proven to be far less distracting to use than real time systems.
Unfortunately, with batch type systems, under certain circumstances inadvertent, incorrect and undesirable linking may occur. For instance, after a document is initially created and links are added to the document via a batch linking operation, when the document is altered, the links in the document may no longer be correct. For instance, where the phrase xe2x80x9cMike Johnson""s CT heart imagexe2x80x9d in a document is linked to a CT heart image for Mike Johnson and a physician edits the document so that the phrase reads xe2x80x9cJohn Thomas"" CT heart imagexe2x80x9d, the edited phrase most likely should no longer be linked to Mike Johnson""s CT heart image. Instead, where a CT heart image for John Thomas"" exists, it may be appropriate for a new link to be made to the John Thomas image. Similarly, where a system stores both a general pamphlet related to CT imaging and Mike Johnson""s CT heat image, an initial document phrase xe2x80x9cCT heart imagexe2x80x9d may properly be linked via batch processing to the general CT imaging pamphlet. However, when a post-batch processing document edit adds the qualifier xe2x80x9cMike Johnson""sxe2x80x9d before the initial phrase xe2x80x9cCT heart imagexe2x80x9d, despite the fact that the appropriate link may be to Mike Johnson""s CT heart image, the initial link will still exist to the CT imaging pamphletxe2x80x94an undesired and inappropriate link.
Incorrect links lead to system user confusion and, in the case of health records, may lead to unacceptable misdiagnosis of physical ailments. For instance, where a physician links to one patient""s CT heart image believing that the physician is linking to another patient""s CT heart image, the consequences may be devastating.
Similarly unacceptable results can occur when the document or record is analyzed by a batch type processing system for document or record characteristics that are used to identify markup language tags (e.g., XML tags) or other record codes to be inserted into the document, the tags or codes are inserted and then the record is subsequently modified. For instance, a batch process may add XML tags around the text xe2x80x9cHillary Clintonxe2x80x9d which is later changes to xe2x80x9cthe town of Clinton, Ill.xe2x80x9d. In this case XML tags corresponding to Hillary Clinton but remaining associated with the town of Clinton would clearly be erroneous and may be employed subsequently to cause unintended and incorrect linking or other actions.
Therefore, it would be advantageous to have a method and apparatus which facilitates unambiguous linking between record references in a first record and referenced records or segments in a second record. In addition, it would be advantageous to have a method and apparatus for automatically inserting markup language tags such as XML or HTML into records either as the records are formed or in a batch mode. Furthermore, it would be advantageous to have a batch link generating system where document edits that follow batch linking do not result in erroneous hyperlinking and other tag or code related actions.
Hereinafter the term xe2x80x9cspecifying referencexe2x80x9d (SR) will be used to refer generically to each of a DR and a DR/MR combination or a DR/MR/MR combination.
An exemplary embodiment of the invention includes a system wherein link ambiguity is rendered unambiguous by imposing a rule set which specifies which of two or more SRs should be selected when two or more SRs and overlap. It has been recognized that in most cases when two possible DR/MR combinations or DRs, which overlap are identified, the user wishes to form a link to a record segment associated with the longer of the two SRs as the longer of the SRs typically more specific than the shorter. Therefore, a preferred rule is that the longest of two SRs is selected. For example, when a first DR/MR combination is xe2x80x9cprevious ECGxe2x80x9d and a second DR/MR combination is xe2x80x9cprevious ECG reportxe2x80x9d, a link is formed to the combination xe2x80x9cprevious ECG reportxe2x80x9d as that reference is the longest and most specific.
The invention also includes a system wherein link ambiguity between DRs or MRs which are associated with more than one other DR or MR is rendered unambiguous through specification of rules used to select one DR/MR combination over another. For example, where the term xe2x80x9cpreviousxe2x80x9d is proximate both DRs xe2x80x9cECGxe2x80x9d and xe2x80x9cX-rayxe2x80x9d such that the term previous could modify either of the two DRs, a rule set is specified which enables the system to select one DR/MR combination over the other. For instance, the rule set may specify that when a single MR is proximate two DRs, the system selects the DR/MR combination corresponding to the first DR or corresponding to the DR which is closest to the MR. Other rule sets, are contemplated, the important characteristic of the sets being that some rule set is provided to minimize ambiguity.
In addition, the invention also includes a system wherein, instead of building URLs when an SR is identified, a processor uses a lookup table to identify a suitable URL which corresponds to the identified SR. For example, in the case of a medical facility, medication information and dosing regimen may routinely be referenced in patient records. In this case, where each brochure and schedule is electronically stored at a known address and can be referenced by a specific SR, the SRs and known addresses are correlated and stored in a lookup table. When an SR is recognized in a record, the table is accessed, the address corresponding to the SR is identified and a link is formed. This aspect of the present invention is particularly useful where a small number of records may routinely be referenced in other records.
Moreover, the invention also includes a system which automatically inserts tags into records to render the records useful in tag enabled applications. To this end, it has been recognized that record segments which are often related to specific types of data will have a specific and recognizable format or will include specific text or graphical indicia. Because the formats, text and/or indicia are recognizable, the information in the formats can be identified as a specific type by a processor which is programmed to search for and identify such information. Once a segment type is known, tags which can be recognized by a tag enabled application can be inserted in the record which is then tag enabled (i.e. can be used by the tag enabled application).
Thus, one object of the present invention is to eliminate ambiguity between SRs where two SRs overlap or a shorter SR is included within a longer SR.
Another object of the invention is to automatically determine whether or not tags may suitably be added to a record to identify specific record segments and information types therein and, when appropriate, to automatically add the tags to render the record tag enabled so that a tag enabled application can identify specific information within the record.
One other object of the invention is to ensure that, when modifications are made to a record which includes tags, the tags remain correct. To this end, the invention includes a feature whereby a processor monitors modifications to a record which includes tags and, when a modification effects tag correctness, the processor performs one of several different functions to ensure that incorrect tags are removed from the record. To this end, one function may be to eliminate all tags in the record. An extended function may be to, after eliminating all tags, reinsert tags into the record where appropriate. Other functions are contemplated.
One other object of the invention is to facilitate a simpler linking process for linking references to a first record which appear in a second record to the first record. To this end, a look-up table is used.
A further object of the invention is to ensure that tags are verified prior to being used to facilitate any action. In this regard, it has been recognized that under certain circumstances tags or record codes that have been added to a record or document in the past may in fact be rendered inaccurate by subsequent changes to the record or document or, indeed, to records that are linked to a document. For example, where a batch linking process is performed on a record and the record is stored, a system user may subsequently access and alter the record content in a manner that renders at least some of the record tags inaccurate.
To overcome the problems associated with inaccurate tags and codes, the invention verifies that tags and/or codes are accurate prior to any action related thereto being performed. For instance, verification may include, when a command requiring an action related to a tag is received, first verifying that the tag is accurate. As another instance, verification may be performed whenever an editing cursor is removed from a document segment that is associated with a specific tag or record code. Similarly, where a sub-set of record segments include information that can be used to characterize a first record segment for tagging or coding purposes, verification may occur whenever an editing cursor is removed from the related segment sub-set. As one other instance, whenever a record is stored or accessed tags may be re-verified. Here, verification upon access ensures that if a DR or DR/MR combination is no longer valid, tags associated therewith will be removed from an accessing document. Other methods to ensure tag verification prior to an action include re-identifying tags and codes in a record or record sections prior to e-mailing, when the record or segment is copied into an operating system clipboard (assuming it may be pasted or inserted into another record by a program presumably unable to verify tags), or when the modified record or record portion is inserted into another record.
Verification may take several different forms including, but not limited to, eliminating tags, rendering tags unactionable until a user recognizes that the tags may not be accurate and requiring affirmative recognition of potential inaccuracy by the system user, eliminating tags and then re-identifying tags and codes, etc. In addition, tag verification may be on a document wide basis so that all tags are verified whenever any document modification is made or, in the alternative, may be on a document section basis whenever a modification is made to a document segment or segments that are known to only affect the characteristics of a sub-section of the document.
In some embodiments tags placed in a record by the user can be left in the record and need not be removed prior to an action being performed. In other cases user defined tags and codes may have to be removed for automatically inserted (e.g., batch inserted) tags and codes to be valid. For example, when the automatically inserted tags are XML tags and the user provides additional XML tags that incorrectly span a series of the automatically inserted tags that are in a fixed cascading or nested hierarchy, the user defined tags may have to be eliminated. Here, the user may be given a choice as to whether to accept the automatically provided tags and the removal of the user provided tags or to reject the automatically provided tags. The step of requesting the guidance of a user may be used any time a user provided tag is in conflict with tags that are automatically provided.
It should be appreciated that the batch verification aspect of the present invention is provided for the same reason as the real time code verification aspects described below. Both batch and real time verification prior to performance of an action associated with a record code are provided to ensure that codes are accurate and hence to avoid confusion.
These and other objects, advantages and aspects of the invention will become apparent from the following description. In the description, reference is made to the accompanying drawings which form a part hereof, and in which there is shown a preferred embodiment of the invention. Such embodiment does not necessarily represent the full scope of the invention and reference is made therefore, to the claims herein for interpreting the scope of the invention.